In various Copy Protection Systems (CPS) where the content has to be transferred across a publicly accessible communication channel, such as an insecure link between computers or a drive/host interface in a PC, a procedure occurs where a hardware device and a software application have to prove to each other that they are trustworthy. This procedure is called authentication. An important step in the authentication procedure is a mutual exchange of Public Key certificates. A public key certificate is a short statement, digitally signed by a well-known and trusted Certification Authority (CA), that attests to the fact that a certain device or application with an identification number ID has a public key (PK). Below, both the device and the application will also be referred to as parties. The PK of the CA is commonly known, and can be used by any party to verify the signature of the CA on the certificate.
To enable this process, each party holds a number of secret keys called Private Keys. These keys and the control flow using them should be well protected in order to prevent hackers from circumventing the CPS. However, in the long run, it is likely that some or even many devices as well as applications, such as playback software, are hacked, and thereby unauthorised content copying is performed.
In order to make such unauthorised copying more difficult, so-called revocation has come to use. A Certificate Revocation List (CRL) is prepared, containing information about which parties are revoked. As a part of the authentication procedure, all parties are forced to read the CRL, and if at least one of the two interacting parties is revoked the procedure is interrupted. There are two kinds of CRLs. A White List (WL) lists all parties that are compliant at a certain point of time. A Black List (BL) lists all devices that have been revoked. For the purposes of this application there is no difference in the information that the WL and the BL contain, since knowledge of all revoked devices determines which are still compliant, and vice versa.
However, there are differences in how they are interpreted and used. When using a BL, a first party, or verifying party, that wishes to determine that a second party, or proving party, is not revoked, has to obtain the complete BL. When using a WL, the verifying party only has to obtain that part of the WL which refers to the proving party. Therefore the use of a White List is advantageous in terms of storage requirements and bus-transmission loads in the CPS. This is of particular importance when the verifying party is a device having little computing power, such as an optical drive. Processing and parsing a long BL would be burdensome for such a device.
However, simple white-listing requires that every party gets its own certificate attesting to its state of non-revocation, resulting in excessive network or disc-storage overhead. To mitigate this drawback, a two-step approach as disclosed in WO03/10788 (attorney docket PHNL020543) and WO03/10789 (attorney docket PHNL020544) is useful. The proving party not only supplies its Public Key Certificate, but also a Groups Certificate (GC). The GC is a concise proof of the fact that one or more groups, to one of which the proving party belongs, has not been revoked. The same GC can be used by many parties, i.e. all parties that are mentioned in the GC. Effectively the entire CRL has been split into GCs, which are individually signed and which are distributed to the communicating parties. One way of using the GCs, according to the above-mentioned international patent applications, is to indicate the upper and lower boundaries of each group represented in the GC. When a party in a particular group loses its status as authorized party, one or more new GCs will be generated. A further improvement is described in European patent application 04101104.0 (attorney docket PHNL040332). This improvement comprises generating a run-length encoded representation of an authorization status of a number of devices.
In order to have a good hacker preventing effect by using the GCs, the parties should be forced to use fairly recent GCs, in order to use revocation information that is not out of date. Otherwise, the revocation tool is of little use. In U.S. Pat. No. 5,949,877 a method wherein relative creation dates of CRLs are compared is disclosed. The revocation list of a verifying party is up-dated when the party receives a more recent list.
In an implementation of the intentions of U.S. Pat. No. 5,949,877 each GC carries a Sequence Number (SeqNo) indicating the time when the GC was created by the CA. Thus, a higher SeqNo corresponds to a more recent time. Typically, as exemplified above, a new set of GCs is generated after a revocation, each GC carrying an increased SeqNo. Compliant parties have to compare the SeqNo of a received GC to some measure of “freshness”. Typically, this measure is a validity number (VN), such that GCs with SeqNo≧VN will be accepted as valid certificates, and GCs with SeqNo<VN will be rejected. There are several ways for a party to encounter new GCs and VNs, such as via online connections, via discs and by contact with other parties. All compliant parties cache a VN, possibly the highest one encountered so far. Due to the disparity in processing power between PCs and, at least some, typically low-power, peripherals, such as for example optical devices, the storing of GCs is differently handled. Thus, applications cache a complete set of GCs carrying the highest SeqNo encountered so far, while such peripherals do not cache GCs.
However, the use of VNs may cause undesired situations. Consider, for example, a comparison of SeqNo and VN in a playback situation. As a first approach, assume that a drive always caches the highest SeqNo it has ever seen into a VN register thereof, and that the drive, during the authentication procedure, demands that the GC of the playback application has SeqNo≧VN. This way of using SeqNos and VNs is for example considered as an option for a BD-ROM (Blue-ray Disc ROM) standardisation. Then, serious user annoyance could occur in off-line situations as will be described below.
Now consider an alternative use of the SeqNo−VN in accordance with a second approach. During the authentication procedure for playback, a drive uses the VN delivered through the disc, which is to be played. The GC of the application is only accepted if it has SeqNo≧VNdisc. This approach is in a way more user friendly.
However, from the content owners' point of view the second approach has a serious drawback. If an application “App” gets hacked, its secrets can be used to construct a content-stealing hacker application “Rip”, which is then distributed over Internet. The CA will revoke App by listing App as non-authorized in all future WLs; say App is still authorized in GCs with SeqNo=X, but revoked in all GCs with SeqNo>X. Then, in spite of this revocation, Rip can always be used to steal content from all discs with VNdisc≦X. In the first approach this is much more difficult, since the hacker would have to isolate his drive from all new discs.
Consider again the first approach. A user with a laptop and a playback software App has bought a new disc. It turns out that the disc has a VN that is higher than the SeqNo of App, and thus App is refused. The user will then have to update App by downloading (possibly for free) a replacement software. However, if the user does not have access to Internet at the moment, which would occur rather frequently for a laptop owner, no update is possible. In addition to the annoyance that this may cause, the user will not be able to play any old discs either, since the disc drive of the laptop has cached the VN of the disc and will not allow App to run. In other words, the discs that have always worked suddenly stop working, until the user has been able to download the updated software. There are several other, rather common, situations where the VN of the drive will be increased such that the running of a software application becomes blocked until the user has been able to update the application. One such situation is where a removable drive is communicating with an application that has a SeqNo that is higher than VN of the drive, while interacting with another PC. Another such situation is where multiple software applications on the same PC are communicating with the same drive but are not keeping an equal pace.
Even though the first approach sometimes will result in a situation where the user's application stops working although it is not even revoked, it will most probably be used. Then there will arise a demand for a development that reduces the user annoyance.